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METHODS AND APPARATUSES FOR WIRELESS PACKET HANDLING 
USING MEDIUM ACCESS CONTROL ACTION TABLES 

The present invention relates generally to wireless communication systems and, 
more particularly, to systems and methods for handling data packets to address time 
sensitivity and quality of service (QoS). 

Technologies associated with the communication of information have evolved 
5 rapidly over the last several decades. For example, over the last two decades wireless 

communication technologies have transitioned from providing products that were originally 
viewed as novelty items to providing products which are the fundamental means for mobile 
communications. Perhaps the most influential of these wireless technologies were cellular 
telephone systems and products. Cellular technologies emerged to provide a mobile 

10 extension to existing wireline communication systems, providing users with ubiquitous 
coverage using traditional circuit-switched radio paths. More recently, however, wireless 
communication technologies have begun to replace wireline connections in almost every 
area of communications. For example, wireless local area networks (WLANs) are rapidly 
becoming a popular alternative to the conventional wired networks in both homes and 

15 offices. 

Circa 1990, the IEEE 802 standards committee formed the 802.11 Wireless Local 
Area Networks Standards Working Group to develop a global standard for radio equipment 
and networks operating in the 2.4 GHz unlicensed frequency band for data rates of 1 and 2 
Mbps. After its introduction, the various versions of the 802.1 1 standard rapidly formed the 

20 basis for standardization of WLAN networks and devices in the United States. Similar 
efforts in Europe have evolved around the HIPERLAN standard. 

Consumers will, naturally, compare services available using wireless technologies 
with services available using wireline service. Wireline services using, e.g., Ethernet or 
Asynchronous Transfer Mode (ATM) protocols provide, among other things, the capability 

25 to deliver audio and video data across networks. These services have different 

requirements. Audio data, for example, does not require the packet-error reliability required 
of data services, but cannot tolerate excessive delay. Video data can in general suffer more 
delay than audio, but is relatively intolerant to delay jitter. These delay and packet-error 
rate considerations may be best supported by a connection-oriented service, wherein the 

30 parameters are negotiated and established at the commencement of each connection. In 
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addition to different types of data, many of today's wireline systems support services which 
provide differentiated quality of service (QoS) levels. 

In general, the term QoS refers to set of qualitative and quantitative traffic 
characteristics (e.g. throughput, service interval, packet size, delay, jitter, priority, type, 
5 etc.), which describes a traffic flow in support of a specific application. In wireline 

systems, QoS issues can be neglected since data rate is very high and the physical layer's 
error rate is very low. However wireless systems incur very high per-packet overhead with 
limited bandwidth, so the same does not apply to wireless systems, e.g., 802.1 1 WLANs. 
For example, a significant percentage of the available data rate in wireless systems is 

10 consumed by packet fragmentation, interframe spacing and MAC-level acknowledgment. 
In addition heavy traffic load increases collisions and backoffs, so frame delivery time 
increases further. Frequent retransmissions also cause unpredictable delays on the order of 
tens to hundreds of milliseconds and transmission of pending frames could be blocked. The 
quality of most multimedia services involving voice and video transmission deteriorate 

15 dramatically if delay increases above certain level. This is a major stumbling block 

associated with the provision of these types of services in wireless communication systems. 

Accordingly, it would be desirable to develop wireless communication systems and 
methods which reduce delay and provide mechanisms which address QoS concerns in order 
to, for example, provide audio, video and other delay sensitive services 

20 Systems and methods according to the present invention address this need and others 

by providing wireless communication systems that allocate a portion of the MAC 
functionality to a hardware portion of the MAC layer and a portion of the MAC 
functionality to a software portion of the MAC layer. For example, responses to received 
packets having greater QoS-related time sensitivity can be identified and handled entirely 

25 within the hardware portion of the MAC layer to reduce delay. By contrast, less time 

sensitive MAC processing steps can be performed in the software portion of the MAC layer. 

According to one exemplary embodiment of the present invention, a method for 
handling data packets in a medium access control (MAC) layer can include receiving a data 
packet, forwarding the data packet to a hardware portion of the MAC layer in a receive 

30 chain, determining, in the hardware portion of the MAC layer in the receive chain, a packet 
type associated with the received data packet, selectively triggering the hardware portion of 
the MAC layer in a transmit chain based on the packet type; and otherwise, sending an 
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indication to the software portion of said MAC layer of the receive chain for generation of 
the response. 

According to another exemplary embodiment of the present invention, a wireless 
communication device can include a receiver for receiving a data packet, a medium access 
5 controller (MAC) having a hardware portion and a software portion, wherein a packet type 
associated with the received data packet is determined in the hardware portion of the MAC 
and a receive action table, in the hardware portion of the MAC, having hardware processing 
functions stored therein for selected packet types, wherein if the packet type of the received 
data packet is one of the selected packet types, then an associated hardware processing 
10 function is performed and otherwise wherein an indication is given to the software portion 
of said MAC. 

The accompanying drawings illustrate exemplary embodiments of the present 
invention, wherein: 

FIG. 1 depicts a WLAN system in which the present invention can be implemented; 
15 FIG. 2 depicts a frame exchange sequence; 

FIG. 3 shows an interaction between hardware (HW) medium access layer and a 
software (SW) medium access layer according to an exemplary embodiment of the present 
invention; 

FIG. 4 is a flow diagram illustrating an exemplary method for handling data packets 
20 in a medium access layer according to an exemplary embodiment of the present invention; 

FIG. 5 is a block diagram of an exemplary WLAN SDIO card, which could be 
inserted into the SDIO slot of the PDA, incorporating an exemplary embodiment of the 
present invention; and 

FIG.6 is an exemplary RX Action table according to an exemplary embodiment of 
25 the present invention. 

The following detailed description of the invention refers to the accompanying 
drawings. The same reference numbers in different drawings identify the same or similar 
elements. Also, the following detailed description does not limit the invention. Instead, the 
scope of the invention is defined by the appended claims. 
30 In order to provide some context for this discussion, an exemplary WLAN system 

will first be described with respect to Figure 1. Those skilled in the art will appreciate, 
however, that the present invention is not restricted to implementation in WLAN systems. 
Therein, a wireline network 10 (e.g., an Ethernet network) has a file server 12 and 
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workstation 14 connected thereto. Those skilled in the art will appreciate that typical 
wireline networks will serve numerous fixed workstations 14, however only one is depicted 
in Figure 1 for simplicity. The wireline network 10 is also connected to a WLAN 16 via 
router 18. The router 18 interconnects the access points (AP) of the WLAN 16 with the 
5 wireline network, through which the access points can, for example, communicate with the 
file server 12. In the exemplary WLAN system of Figure 1, three cells 20, 22 and 23 (also 
sometimes referred to as a Basic Service Set (BSS) or Basic Service Area (BSA) are shown 
each with a respective AP, although those skilled in the art will once again appreciate that 
more or fewer cells may be provided in WLAN 16. Within each cell, a respective AP 

10 serves a number of wireless stations (W) via a wireless connection. 

According to exemplary embodiments of the present invention, the transmission of 
signals between APs and respective wireless stations W is performed using wireless 
communication signals in accordance with one of the 802.1 1 standards. However, those 
skilled in the art will appreciate that the present invention is not so limited and may be 

15 implemented for communication of signals in accordance with other formats and standards. 
As mentioned earlier, the introduction of QoS capability into the 802.11 standards will 
result in additional time sensitive functionality during a frame exchange sequence to be 
carried out at the MAC layer. To illustrate the time sensitive nature of QoS related frame 
exchange signaling, consider the exemplary frame exchange sequence shown in Figure 2. 

20 Therein, a frame exchange sequence between an AP and a first wireless station W 

occurs during a first transmission opportunity (TXOP1). The AP transmits QoS data blocks 
spaced apart from acknowledgements from the wireless station W by short interframe 
spaces (SIFS). A QoS Null message is transmitted by the wireless station W at the last 
frame of TXOP 1. In order to grant another transmission opportunity to another wireless 

25 station W, the AP uses the message QoS CF-Poll. Then, during TXOP 2, the other wireless 
station W transmits its QoS data frames to the AP which are likewise acknowledged by the 
AP. Although this example illustrates all data frame transmissions being acknowledged by 
the recipient station, 802.1 le permits MAC level acknowledgements to be optional, i.e., a 
station need not acknowledge a correctly received frame based on the ACK policy field in 

30 the incoming frame. This further tightens the time constraints associated with data packet 
transmission and reception in such systems since this means that a next package needs to be 
ready for transmission after the SIFS time period has expired. Generally speaking QoS- 
related changes to wireless protocols have introduced time sensitivity in the MAC layer 
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processing (1) during data packet reception, when fields have to be extracted, further 
software processing has to be done on the data packet or a time sensitive response has to be 
sent back and (2) during data packet transmission, when some fields have to be inserted in 
the data packet or some follow-up action has to be taken. 
5 According to exemplary embodiments of the present invention, the time sensitivity 

associated with these, and other, QoS -related wireless protocols can be achieved by 
partitioning MAC level functionality between hardware and software. For example, 
according to exemplary embodiments of the present invention, this partitioning can be 
achieved by a register interface in the hardware. Due to the varied types of MAC packets 

10 currently defined for transmission, some of which are shown in Figure 2, and the 

expectation that more packet types will be added in the future in the various standards, 
MAC hardware according to the present invention is designed to deal with the time 
sensitive nature requirement of each type of packet and cater to it as specified by the 
software. Note that as used herein the term "packet type" is intended to include packet 

15 types, packet sub-types and the combination of packet-types/sub-types. In particular, 

exemplary embodiments of the present invention provide two tables in the MAC hardware, 
which tables are referred to herein as the Rx Action table and Tx Action table. 

An exemplary high-level implementation of these two tables is shown in Figure 3. 
Therein, an exemplary interaction between the physical layer, hardware (HW)-MAC layer 

20 and the software (SW)-MAC layer is illustrated. Both a transmit chain 30 and a receive 

chain 32 are shown which can be integrated into a single MAC controller. Note that an Rx 
Action table 34 is included within the HW-MAC layer associated with the receive chain 32 
and that a Tx Action table 36 is included within the HW-MAC layer associated with the 
transmit chain 30. An exemplary processing flow for this MAC architecture will now be 

25 described with respect to the flow diagram of Figure 4. 

Therein a data packet is first received by a receive module 38 of the physical layer at 
step 50. The data packet is then forwarded to the HW-MAC layer in the receive chain 32 at 
step 52. The HW-MAC layer verifies the data packet and determines what type of data 
packet has been received, e.g., from header information, at step 54. The Rx Action table 34 

30 determines what action to take in response to the received data packet based on its packet 
type at step 56, If the packet type indicates that a faster response is desired, then a trigger 
can be sent directly from the HW-MAC layer in the receive chain 32 to the HW-MAC layer 
in the transmit chain 30. Since this path circumvents the software portions of the MAC 
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layer, the resulting response will be faster and less delay will be generated. Examples of 
data packet types and corresponding actions are provided below. If no fast -track response is 
indicated by the Rx Action table 32, then an indication is sent on to the software (SW)- 
MAC layer in the receive chain 32, wherein it is processed and a software (SW)-MAC 
5 generated response is forwarded to the transmit chain 30 at step 58. 

Having described an exemplary embodiment for handling data packets in a MAC 
layer according to the present invention, some more detailed examples of Rx Action table 
34 and Tx Action table 36 will now be provided. The HW-MAC layer in the receive chain 
32 includes an address filter which determines the destination address of the incoming 

10 packet which, along with the ACK policy (for QOS frames), is a mechanism for 

determining the set of actions can be taken for this particular packet. The incoming packet 
can be categorized as, for example, one of the following destination types: (1) a packet 
having a unicast address for this particular wireless station, (2) a packet having a unicast 
address for other wireless stations, (3) a packet having a multicast group address of which 

1 5 this particular wireless station is a member, (4) a packet having a multicast group address of 
which this particular wireless station is not a member and (5) a packet having a broadcast 
address. Based on their different destination address types, received frames are treated 
differently. For example, if an incoming frame is intended for this particular wireless 
station, and if it is meant only for this particular station (i.e., if it has a unicast address), then 

20 the receiving wireless station W shall return an ACK frame to the transmitting wireless 

station W. Alternatively, in case the destination address of the incoming frame is a member 
of a multicast group for which the frame is intended, then the receiving wireless station W 
should not respond with an ACK frame, but should instead be indicated to the SW-MAC 
layer. The same mechanism should be provided to handle incoming frames having a 

25 broadcast destination address. 

On the other hand, if the destination address of an incoming frame is a multicast 
address of which the wireless station is not a member, then the frame should be filtered out 
at the HW-MAC layer and should not be indicated to the SW-MAC layer. In addition to 
considering an incoming frame's destination address type, RX Action tables according to 

30 exemplary embodiments of the present invention also can be indexed according to whether 
an ACK policy field is present in, for example, an incoming QOS frame. 

Based on this, or other, categorizations of an incoming data packet, the RX Action 
table 34 can be indexed to output an action associated with the determined packet type. 
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Such actions can be represented as bit fields in the Rx Action table entry word and include, 
for example, the following actions. 

1. Trigger the transmission of a control packet (data packet in the case of an 
incoming CF-Poll frame) which has been preprogrammed. This action can be performed 

5 when, for example, an incoming packet has is one of the following types: CF-Poll -HData, 
PS-Poll, Data- ACK and RTS-CTS sequence. 

2. Trigger an interrupt after a particular number of data packet bytes have been 
received. This action can, for example, be triggered for cases where a new frame type is 
introduced into a standard. The SW-MAC layer will need to act on to be able to operate on 

10 the new frame type, most likely in a time critical fashion. Thus, when this new frame type 
is received the SW-MAC can enable this interrupt in the RX Action table after, for example, 
a configurable number of bytes were received. 

3. Trigger the transmission of a packet following the DCF medium access rules. 
The frames may be queued in the HW-MAC as they are received from the host. The HW- 

15 MAC layer takes care of sending the frames after following the DCF protocol. This will 

reduce the workload of the SW-MAC and reduce the number of processor cycles associated 
with MAC level processing. 

4. Write the incoming packet in memory and generate an interrupt for software to 
process it. This action can be triggered based on destination address filter results which 

20 indicate that the HW-MAC layer will either write the frame to a memory device where the 
SW-MAC layer can access it. 

5. Perform a CRC check on the incoming packet. In some test cases it may be 
desirable to forego performing a CRC check on incoming packets. Providing the trigger for 
CRC checking/not checking in the RX Action table provides an efficient mechanism for 

25 handling such cases. 

6. Update the TXOP holder address. This action can be triggered when, for 
example, an incoming frame is a CF-Poll frame. 

7. Update NAV with the duration id of the incoming packet. This action will be 
triggered for many types of incoming packets in the RX Action table. However, the virtual 

30 carrier sense algorithm associated with the exemplary 802.1 le standard does not need to 
operate on all packet types, e.g., the PS-Poll frame does not have a Duration Id field 
defined. For this reason, the HW-MAC layer should not update the NAV with the 3 rd and 
4 th byte of the PS -Poll frame, which is generally where the Duration Id is located. The 
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NAV should be updated with a remaining CF duration value, if the field is received in the 
beacon in the middle of a CF period. 

8. For beacon packets, a number of different actions can be indicated in the RX 
Action table. For example, the beacon can be filtered out beacon based on the BSSID, 
5 SSID and/or Capability info, the TSF can be updated per the BSS/IBSS update criteria in 
the beacon or the NAV can be updated if the beacon starts a CFP. 

Similarly, the TX Action table 36 can be organized by packet type/action. Based on 
the packet type/subtype, the TX Action table 36 can be indexed to output an action 
associated with the determined packet type. Such actions can be represented as bit fields in 
10 the Tx Action table entry word and can include, for example, those set forth below. 

1 . Insert CRC for the packet to be transmitted. This action can be performed, for 
example, for test purposes when it is desirable to validate the receiving wireless station's 
CRC module by receiving a frame for which the CRC has been intentionally garbled. Using 
this option the CRC generation module of the HW-MAC for the transmitting wireless 

15 station can be disabled. 

2. Insert source MAC address/BSSID. Enabling this action in the TX Action table 
may lead to less overhead in the SW-MAC for outgoing frames. This action can be used 
both for the auto-response frames triggered by the HW-MAC in the receive chain, as for 
occasions where the transmitter's and receiver's address needs to be swapped. 

20 3. Fragment the packet based on the fragmentation parameters. The fragmentation 

related parameters can be provided to the HW-MAC which can then take care of the 
fragmentation of the packet without any assistance from the SW-MAC layer. 

4. Expect specified response in SIFS time after transmitting packet. This may be 
indicated by the SW-MAC to the HW-MAC when the HWMAC Rx needs to prepare the 

25 receive state machine for an incoming frame right after transmitting a frame. 

5. Generate interrupt(s) upon transmission of packet. This interrupt action may be 
enabled in the TX Action table by the SW-MAC in order to know whether a previously 
programmed packet has been attempted by the HW-MAC and to provide a feedback/result 
of the attempt. 

30 6. Insert timestamp and/or DTIM count in beacon. This action can be triggered 

whenever the TX Action table receives a packet for transmission from the SW-MAC layer. 

Those skilled in the art will appreciate that the foregoing example, which refers to 
the 802.1 le standard, is purely illustrative and that the present invention can be applied to 
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communication systems which operate in accordance with other standards. Readers who 
are interested in operations of 802.1 1 and/or 802.1 le are referred to the IEEE Standard for 
Information Technology, Part 11: Wireless LAN/MAC and Physical Layer (PHY) 
Specifications, ANSI/IEEE 802.1 1 (1999) and the Draft Supplement to the IEEE Standard 
5 for Information Technology, Part 1 1 : Wireless LAN/MAC and Physical Layer (PHY): 
MAC enhancements for Quality of Service (QoS), ANSI/IEEE 802.11e/D4.0, November 
1999, both of which are expressly incorporated here by reference. 

The allocation of MAC functions between hardware and software according to the 
present invention can be provided in any wireless communication system or device. To 

10 further illustrate the present invention, an example is shown in Figure 5 with respect to an 
embedded wireless LAN chip in a PDA device. Therein, an exemplary MAC controller 60 
(ASIC chip) is illustrated which includes a general purpose microprocessor 62, at least one 
memory unit 64, a HW-MAC unit 66 and an SDIO interface unit 68. Those skilled in the 
art will appreciate that other functional blocks, e.g., a DMA controller, other I/O ports, a 

15 power converter, additional memory devices, etc., can be included however only these four 
functional blocks are depicted to simplify the discussion. The HW-MAC ASIC unit 66 
communicates with a transmitter and receiver (not shown) and includes the RX Action table 
and TX Action table described above. According to exemplary embodiments of the present 
invention, those packet types received by the HW-MAC ASIC chip 66, and identified in the 

20 RX Action table as designated for expedited response and/or other hardware action, are 

handled within HW-MAC ASIC chip 66. For example, if HW-MAC ASIC chip 66 receives 
a CF-Poll packet, its RX Action table may specify that an automatic, prestored response be 
retrieved from memory 64 and sent to the transmitter for transmission without involving the 
general purpose microprocessor 62 in this part of the process. Notwithstanding an 

25 indication in the RX Action table to perform a certain HW-MAC action on an incoming 
packet, there may also be pay load data to be processed by the general-purpose 
microprocessor 62 and, for example, output via SDIO interface 68 to the wireless PDA 
device. 

A more detailed example of an RX Action Table according to the present invention 
30 is provided as Figure 6. Therein, the rows specify the various packet types that can be 

received by the MAC. The columns represent the actions which the HW-MAC is capable of 
performing. This table can be translated into a 64-bit register in the HW-MAC where the 
HW-MAC indexes on, for example, the 02-07 bits of the incoming packet. The HW-MAC 
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uses theses bits to determine what kind of address type is associated with the incoming 
packet and then takes the corresponding action as specified in the corresponding RX Action 
table bits. The 64 bit register may be designed in such a way that a group of bits 
(corresponding to an action required) are allocated to the 'Unicast Self address class, others 
to the 'Multicast self address class and like wise for the 'Multicast others', broadcast and 
'Unicast others 5 address class of the incoming frame's receiver address. The functionality 
associated with the Special Action column in Figure 6 according to this exemplary, but 
purely illustrative, embodiment is described below in Table 1. 



CI 


Beacon can be either Broadcast(then process) or not(it is ignored, in which case it is an 
invalid packet) 

1) Parse the beacon to note the origin of the beacon (IBSS or BSS). In case it is from an 
AP and this wireless station is a member of this BSS then update the TSF value of this 
wireless station with the TSF in the beacon. In case it is an IBSS beacon and this wireless 
station is a member of this IBSS then update only if the value of TSF in beacon is greater 
than this wireless station's TSF value. In all other cases ignore the TSF value in the 
beacon. 

2) update NAV if the CF Parameter element starts a CFP; and 

3) generate receive indication to the SW-MAC. 


C2 


The address of RR and CC are BSSID. Matching result can be either "self or "other". 


C3 


Send CTS if NAV==0, otherwise, ignore. 


C4 


For CTS Unicast self, HW MAC should send pending fragment or MSDU automatically. 


C5 


Continue sending the next frame if this was not the last frame. Otherwise, generate a 
transmission status indication to the SW-MAC. 


C6 


If this wireless station is CF-aware then do not generate any interrupt to the SW-MAC but 
update the NAV. 


C7 


Store the TXOP Holder address. 


C8 


Auto send QoS ACK or ACK (as configured by the SW-MAC).. 


C9 


1) Do the decryption if WEP bit=l; and 2) generate a receive indication to the SWMAC. 


CIO 


Auto send CF-ACK/ACK if required and generate Receive Indicate interrupt. 


Cll 


Store the TXOP value in the TXOP register; 

Check whether a QoS Data frame has to be sent in response. If not then send the QOS 
Null frame; and 

In case there is QOS data frame to be sent in response to a +CF-Poll frame then fetch the 
data frame from the predefined memory location and send it. 



Table 1 



The above-described exemplary embodiments are intended to be illustrative in all 
respects, rather than restrictive, of the present invention. Thus the present invention is 
capable of many variations in detailed implementation that can be derived from the 
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description contained herein by a person skilled in the art. From the exemplary Rx Action 
table of Figure 6, it can be seen that the SW-MAC layer enables particular feature(s) in the 
HW-MAC on initialization. Accordingly, in order to suit varying architectures a particular 
option may be disabled or enabled in the HW-MAC layer. If disabled, then that 
5 functionality will either be carried out in the SW-MAC or eliminated. Thus, the present 
invention's provision of Rx/Tx Action tables provides flexibility in the e.g., ASICs, with 
respect to frequent changes in communication standards. All such variations and 
modifications are considered to be within the scope and spirit of the present invention as 
defined by the following claims. No element, act, or instruction used in the description of 
10 the present application should be construed as critical or essential to the invention unless 
explicitly described as such. Also, as used herein, the article "a" is intended to include one 
or more items. 



